-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Associate a trailing end-of-line comment in a parenthesized implicit concatenated string with the last literal #15378
base: main
Are you sure you want to change the base?
Associate a trailing end-of-line comment in a parenthesized implicit concatenated string with the last literal #15378
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
|
4070d80
to
eef2e67
Compare
eef2e67
to
3d612d1
Compare
881b881
to
bde498b
Compare
a = ( | ||
"a" | ||
"b" "c" # belongs to the f-string expression | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand the change but I want to confirm as to why does this comment belongs to the f-string expression. I think the reason is that without that, the formatting might move the last part of the string to it's own line along with the comment which means the comment won't be applicable for the last second part. Is that correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an edge case where there's no "right" solution because the formatter can't tell if the comment belongs to the middle part, the last part, or the entire f-string.
That's why I decided to associate it with the f-string. This matches the default behavior where we associate a comment with the outer most node that ends right before it. We could also decide to associate it with the last part, if we think this is more appropriate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that seems like a reasonable default. It might be worth adding this as a comment to that case.
@@ -355,6 +355,41 @@ fn handle_enclosed_comment<'a>( | |||
AnyNodeRef::ExprGenerator(generator) if generator.parenthesized => { | |||
handle_bracketed_end_of_line_comment(comment, source) | |||
} | |||
AnyNodeRef::StmtReturn(_) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to cover other statements like raise
and assert
?
raise Exception(
"a"
"b" # belongs to `b`
)
assert False, (
"a"
"b" # belongs to `b`
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, only statements that use FormatStatementsLastExpression
...tter/resources/test/fixtures/ruff/expression/join_implicit_concatenated_string_assignment.py
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like a wise behavior change. Is the intent that we'd eventually do the thing that you called "too risky for a bugfix release", so that we can collapse these in some cases?
Summary
This PR implements a fix for the implicit concatenated string formatting. Specifically for strings where the last part has a trailing end-of-line comment and they're in the value position of an assignment (including type alias) or return statement.
For example:
got reformatted to
which is undesired because the
noqa
comment is now misplaced. It's also impossible to move it back to the right place because the formatter keeps moving it out of the parentheses.The reason this is happening is because we try to match Black's formatting for assignments:
Notice how the comment gets moved out.
The relevant logic for this behavior lives here
ruff/crates/ruff_python_formatter/src/statement/stmt_assign.rs
Lines 349 to 449 in 424b720
and
inline_comments
stores all the comments that should either be moved in or outside the parentheses.Ideally, we would adjust this logic (and it's counterpart in
ruff/crates/ruff_python_formatter/src/statement/stmt_assign.rs
Lines 759 to 908 in 424b720
That's why I decided to instead implement it in
place_comment
and associate a comment in a parenthesized f-string expression that's on the same line as the last part with said part, but only if the last part is on its own line.This has two downsides:
Ideally, we'd collapse the following but we'll no longer be able to do that with the changes from this PR:
This used to work before and works for implicit concatenated strings outside of assignment-value positions. I think this is acceptable.
This is directly related to the above limitation. I made this behavior specific to implicit concatenated strings in assignment value positions or return statements. That means that the behavior is somewhat inconsistent to how we e.g. handle implicit concatenated strings embedded in another expression (you can see an example in the snapshot changes)
I'm open to changing the behavior to all implicit concatenated strings. It might be the right move, but I'm not sure. There are trade offs ;)
Fixes #15375
Test Plan
Added snapshots
The ecosystem changes look good to me.